在IAR里新建工程或导入工程后，最常见的卡点之一就是【Device】下拉框里找不到目标芯片，导致链接脚本、启动文件、调试配置都无法按器件生成。这个问题通常不是工程坏了，而是设备支持包没有安装到位，或工程依赖的CMSIS器件包没有落到本机Pack仓库。下面按先定位缺什么、再把Pack装进去、最后验证生效的顺序，把整套流程一次做完整。

做静态检查时，很多团队遇到的不是“查不出问题”，而是“告警太多、误报太多，工程师开始选择性忽略”。IAR C-STAT本身会给出严重度与置信度，目的是帮助筛掉不值得立刻处理的提示，但如果项目配置、规则包选择、抑制方式没有统一口径，噪声仍然会迅速堆高，最后反而拖慢迭代节奏。

在IAR里把运行库切到DLIB后，printf相关问题常见表现是输出缺字、格式不对、浮点不显示、偶发乱码，甚至一调用就跑飞。DLIB本身支持可裁剪的格式化能力与不同的底层输入输出接口，工程一旦同时牵涉C-SPY终端窗口、UART串口重定向、以及不同Printf formatter组合，任何一个环节不匹配都会把问题放大。下面围绕IAR DLIB启用后printf输出异常怎么定位，IAR DLIB库配置与格式化选项应怎样设定，把排查与配置按可执行路径拆开。

map文件本质上是链接器把最终可执行镜像如何落到各个内存区域的账本，想看内存占用，核心不是盯着某一个段名，而是把map里的汇总数字、内存区域与段放置三件事对齐。IAR里只要在链接器的List选项启用Generate linker map file，构建后就会在输出目录生成对应的map文件，后续所有定位都围绕它展开。

在IAR里遇到头文件找不到，很多人第一反应是包含路径没配对，但实际更常见的是路径没有落到正在参与编译的那个目标与配置上。再叠加条件编译宏的影响，同一条包含语句可能在不同宏环境下走到完全不同的头文件分支，看起来就像路径忽然“失效”。下面按可操作的排查顺序，把路径、配置、文件级覆盖与宏定义一并核对清楚。

在IAR里点【Download and Debug】却下载不到目标板，很多人第一反应是怀疑程序有问题，但更常见的原因其实出在连接链路、Flash写入通道、或下载参数与芯片实际状态不一致。把下载流程拆成几步去看，就能快速判断失败发生在“连不上”“写不进”“校验不过”还是“写完跑不起来”，定位会明显更快。下面按现场常见卡点，逐步把Flash Loader与驱动参数的检查路径讲清楚，方便直接照着排。

在IAR里把优化开高后，调试窗口里看不到局部变量、Watch里出现Unavailable、变量值跳来跳去，这通常不是调试器坏了，而是编译器为了生成更紧凑或更快的代码，把变量折叠、搬运到寄存器、甚至直接消掉了。想兼顾性能与可调试性，关键在于先弄清楚变量为什么消失，再把调试信息与保留符号的开关按场景配齐。

断点打上了却一直不停，表面看像是调试器失灵，实际上更常见的原因是编译器优化让源代码与最终指令不再一一对应，或调试信息与当前下载到目标机的镜像不一致。IAR在调试文档里也明确提醒，高优化会让源代码与生成代码的对应关系变弱，变量值与单步体验会变得不可靠。

在IAR的构建流程里，编译阶段能过但链接阶段报Undefined Reference，通常意味着某个符号只有声明没有被成功链接到定义，问题既可能出在源文件未参与链接，也可能出在库文件未被找到、未被正确扫描，或与目标架构和运行库选型不匹配。要把这类问题一次性压下去，建议把排查顺序固定为先确认符号来源与编译产物，再核对库搜索路径与库顺序，最后再回到链接脚本也就是扩展名为icf的配置文件检查放置与选择逻辑。